Mike Boorman: Welcome folks.
Let's take a look at storage accounts, the heart of file
and blob storage solutions in Azure.
When it comes to how your data is structured,
there are three classifications
or methods by which your data can be organized.
The first is structured data.
This is most commonly done using organizational
methodologies like tables or relational databases.
You will learn about this in the next course.
The second is semi-structured data.
This involves using metadata that allows for the storing
of complex data in a way
that is quickly searchable and accessible.
You will learn about this technology
in the next course as well.
The final type is unstructured data.
This is when you store data in different formats, models,
or schemas in the same data store.
Examples include text files, emails, audio files,
video files, other documents, and more.
In Azure, unstructured data is typically stored in blob
or file storage.
Let's level set on what storage accounts are
before we scope further.
Storage accounts are unique namespace
accessible from anywhere.
They're a collection of settings about storage services
and storage account types,
support different types of services.
Always remember that your national
and or regulatory compliance
and security considerations when it comes
to storing data in storage accounts.
The first is standard general purpose V2 or version two.
It supports services including blob storage,
which also includes data lake storage, queue storage,
table storage, and Azure files.
Some common uses for this
are honestly just about most scenarios,
so your blob storage, file shares, queues that you may have,
tables or even disks for virtual machines
and other types of resources.
Premium block blobs support only blob storage,
but also do include the data lake storage option.
Premium storage accounts for block blobs
and append blobs are often used for applications
with high transaction rates,
so you'd use a premium block blob if you work
with smaller objects
or require consistently low storage latency.
This storage is designed to scale with your applications.
We also have premium file shares.
This is specifically geared towards Azure files.
This is a premium storage account for file shares only.
It's recommended for enterprise
or high performance scale applications.
So you would use premium file shares if you require support
for both server messenger block, SMB
and NFS file shares in large enterprise environments
where you know that you have many,
many users constantly requesting access
to different types of files.
And finally, we have the premium page blobs.
As it implies it's for page blobs only.
This is premium high performance storage for page blobs
that are ideal for storing index based
and sparse data structures such as operating systems,
data discs for virtual machines and databases.
Lots of input output operations that are occurring,
and premium page blobs are great for that.
So let's dive into these storage account
services a little bit more.
You have blob storage, table storage, page blobs,
queue storage, Azure files and data lake storage.
And as we saw in the previous with storage account types,
these different services fit into those different service
types and you have to know which service is going
to ideally fit your specific need.
With our types and our services, we also have tiers.
The first is an access type of tier,
and here we have hot, cool, cold and archive.
And as you might guess, each one of those
has a different performance level as far as
how much it costs to write and to read
or input and output or ingress and egress.
But the storage cost for each
of these gets incrementally less
or more depending on how it is.
So an example of low cost storage would be archive
extremely low to store large amounts of data,
but to egress the data out of that archival storage,
is number one, quite slow.
It has to be provisioned first and it is expensive.
Cold and cool are incremental stages up towards hot,
which hot access is assumed
that this data will get accessed on the regular.
And so while the storage cost
for the data on disc is higher than all of the others,
the benefit in performance and quick access is worth it.
Now we've said performance a couple of times.
There are two specific types of performance tiers,
standard and premium.
And each of these, again, is something that needs
to be considered when designing a storage solution
because you don't want to pay for more
than what you're actually needing.
What can commonly happen is
you have a premium performance storage account
that's deployed, has lots of data on it,
but is rarely accessed.
And so you are paying to have that premium performance
that is never really getting utilized
and additional is redundancy.
What do we mean by this?
Well, there's four different types.
There's local or locally redundant storage, abbreviated LRS.
We have Zone, which is ZRS or ZRS.
We have Geo GRS, and we have Read-access Geo or RA-GRS.
And there are some additional combinations that can be done
for each of these types.
But as you can imagine with the increased level
of redundancy comes an increased cost in the storage itself.
Something that is a quick access share,
that you know is for either ephemeral data
or data that isn't super critical.
You would probably put that
on a local LRS storage account blob.
Zone is for a specific zone, so East US,
Central US, East Asia, that type of thing.
Geography is for a whole area.
And Read-access ensures that even if
specific things go wrong in a certain geography,
that the data can still be extricated from
that storage account even with a major outage.
Authentication and authorization.
This is important because we don't want people getting
access to our storage accounts
who shouldn't have access to them.
We do this through access keys, through shared access
or rather share access signatures, SAS.
And in many cases you can even use Azure role-based access
control or RBAC to scope different permissions
and ensure that only those who need
to have access do in fact have access.
Encryption, storage accounts have encryption at rest.
They also have encryption in transit as well as the ability
to integrate with Azure Key Vault.
Why is this all important?
You want to know that when the data is sitting on a specific
disc in a data center, that it is encrypted,
which is encrypted at rest.
This ensures that should someone have access,
gain physical access, even though they have that disc,
they don't have the ability to read the information.
You also want to know that while it's coming off of
that data center to a user or an application,
that people cannot view it while it's being moved
between points, which is what encryption in-transits for.
And that last integration allows all of this to occur
inside of Azure, ensuring that the keys that are used
to do the encryption both at rest and in transit
are not being passed along
or being held in insecure locations.
Virtual network integration, we have this concept
of service endpoints, private links
and firewall rules.
All of these allow storage accounts
to be integrated both into virtual networks,
but to also provide access
through virtual networks, while at the same time
preventing access through certain IP ranges
or even certain IP geographies.
So we have all of these different components that all
come into play when it comes to deploying a storage account
or more specifically when it comes
to taking a deployed storage account
and making sure that it works for the environment
and use that is needed, right?
So for this course, we are examining storage accounts
as a solution.
A solution is always going to find itself in the real world
where interoperability is necessary.
And so this brings up cost optimization.
We have to consider things like access tiers,
how resilient we need the storage accounts to be.
What are the redundancy implications,
not just from a cost perspective
but from a compliance perspective.
And we have to consider the object lifecycle management.
How are we making sure that we are not paying
for the storage of objects
that no longer have any value for the business?
Let's look at a scenario to bring all of this together.
In this first one, we have the need
to migrate 500 terabyte file shares
from on-premises to a cloud.
The shares are accessed from multiple global office
locations, but they're infrequently accessed reference data.
So what could we use?
Well, we could use Azure file storage on a standard tier,
standard performance tier with cool access
and ensure that there is Geo-redundancy.
Let's look at another scenario.
Blob storage for video content.
So here we're storing media assets and other video content.
As a result, it's accessed frequently in regions
during editing, but rarely afterwards.
The total storage will reach one petabyte over the
next three years.
An example of a scenario or a solution that we could create
is an Azure blob storage
with hot and cool tiers, locally redundant storage
and either object lifecycle management
or adding an additional archive tier
to manage long-term costs.
So in this case, there are some companies out there
that really do want to keep their media
and video in perpetuity,
and when this comes into play,
something like archival tiers become very handy.
These are just two scenarios that help us to see
where all these components we've covered
have to be considered when we are designing
a storage account solution.
I hope this has been helpful and informative
and I'll see you in the next lesson.